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Abstract. Recent advances in programming languages study and design have 
established a standard way of grounding computational systems representa¬ 
tion in category theory. These formal results led to a better understanding 
of issues of control and side-effects in functional and imperative languages. 
Another benefit is a better way of modelling computational effects in logi¬ 
cal frameworks. With this analogy in mind, we embark on an investigation 
of inference systems based on considering inference behaviour as a form of 
computation. We delineate a categorical formalisation of control constructs 
in inference systems. This representation emphasises the parallel between the 
modular articulation of the categorical building blocks (triples) used to ac¬ 
count for the inference architecture and the modular composition of cognitive 
processes. 


1. Introduction 

Originally grounded in research work in Artificial Intelligence (AI) and, more 
specifically in AI in medicine and production systems |p^ , Nexpert Object became 
a commercial success in the late eighties and nineties. Its implementation architec¬ 
ture broke new ground in graphical user interfaces, in portability across operating 
environments and in distributed object systems. But powerful innovations also 
went deep into the design of the inference system itself (NXP), which can be traced 
back to that seminal research work in AI. 

In this and a companion paper we offer a formal account of this inference sys¬ 
tems, using recent theoretical advances in the understanding of programming lan¬ 
guage design. In particular, some of the computational effects introduced by the 
NXP design show a denotational semantics best captured with the current tools in 
continuation-passing or monadic styles. 

Continuations. The idea of transforming programs to continuation-passing style 
(CPS) appeared in the mid-sixties M- The transformation was formally codified 
by Fischer and Reynolds in 1972, yielding a standard CPS representation of call- 
by-value lambda calculus. In the context of denotational semantics [^, described 
as the theory of meaning for programs, denotations are usually built with the help 
of functions in some mathematical structures. In CPS these functions are explic¬ 
itly passed an additional argument k representing ’’the rest of the computation”, 
a first step towards full reification of the notion of computation itself. Although 
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most of the work on continuations involves a functional language, usually a frag¬ 
ment of typed or untyped lambda calculus, CPS is also useful in understanding 
imperative languages. Continuations were found to be a major tool for the design 
of interpreters and compilers for many languages, most prominently Scheme, ML 
and Haskell. 

As such, continuations appear as the raw material of control. Operations on con¬ 
tinuations control of the unfolding of a computation—that this translation happens 
in a standard way is a major result of the theoretical work on continuations. Simi¬ 
larly, in inference systems, of which production systems are a well-studied example 
|T8[ , designing a proper behaviour relies on the delicate interweaving of goal-driven 
and data-driven control. Moreover the importance of the relative data-driven nature 
of the flow of control sets inference systems apart from both functional and impera¬ 
tive programming languages. In inference systems, both side-effects and procedure 
calls are mediated through operations on data. This paper shows the relevance of 
the CPS representation for analysis and assessment of inference systems. 

Monads and triples. Originally introduced by Moggi in computer science, 
monads or triples, a notion from category theory j^, were shown to generalise the 
continuation-passing style transformation. Monads can model a wide variety of fea¬ 
tures, including continuations, state, exceptions, input-output, non-determinism, 
and parallelism MM- The monadic style essentially distinguishes between val¬ 
ues and computations ; it sets up a uniform infrastructure for representing and 
manipulating computations with effects as first-class objects [1). More specifically, 
monads introduce a type constructor T through which the type Tr represents a 
computation that yields a result of type r and may have side-effects. Cast in this 
background, continuations arise as a special case of monad translation. 

Inference systems. Inference systems are characterised by a program organi¬ 
zation based on data or event-driven operations. Such an organisation can be 
described as pattern directed-, patterns occurring in the data select pieces of code 
in the system to be activated. Systems organised this way have been used primar¬ 
ily for deductive inference ||^, and, to a lesser extent, for inductive inference or 
learning [^. An inference system has three components: a collection of substruc¬ 
tures, called pattern-directed modules, which can be activated or hred by patterns 
in the data; one or more data structures that may be examined and modified 
by the pattern-directed modules; and an executive, or interpreter, that controls 
the selection and activation of the modules. In traditional production systems the 
pattern-directed modules are called production rules and reside in production mem¬ 
ory while the data structures are stored in the -working memory. The interpreter 
uses various strategies in a recognize-act cycle to select candidate production rules 
and execute their action part. 

In the NXP architecture, this mechanism is supplemented by a goal driven pro¬ 
cess. Informally, goals are investigated by actively looking for patterns in data, a 
search usually called backward chaining as it involves a recursive descent in the gen¬ 
eralized and-or tree representing linked production rules. Such goals are confirmed, 
rejected or considered “not known” as the data collected during the recursive de¬ 
scent trigger some of the patterns of the production rules, a process dually called 
forward chaining. In addition goals are said to be evoked when, hitherto uninves¬ 
tigated, they also depend on data collected during the backward chaining descent 
from initial goals. Eventually every goal sharing a triggered data pattern with an 
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initial goal ends up evoked. These evoked goals are queued for later evaluation once 
the current agenda of goal investigation or data collection completes, their inves¬ 
tigation is suspended or postponed until the current one terminates. Considering 
backward and forward chainings in NXP as computations in the previously men¬ 
tioned sense, goal evocation can be viewed as an effect, comparable, for instance, to 
the escape construct of functional programming languages. Following sections of 
this paper show how to capture backward and forward chainings as computations 
and account for goal evocation in continuation-passing and monadic styles. 

Logical frameworks. Most of the work we are presenting in this and its compan¬ 
ion paper has been designed for validation and checking with Twelf [|^, a logical 
framework developed at Carnegie-Mellon University. In a logical framework such 
as this, a deductive system is used as a device for establishing semantic properties 
of the mathematical or computational object under study. Following Martin-L6f 
introduction of judgements as the foundation for constructive mathematics and 
computer science, logical frameworks represent judgements as types enabling proof- 
theoretic derivations by type reconstruction. Logical frameworks provide a uniform 
judgements-as-types representation of proofs of semantic properties. In this paper 
we use the Twelf deductive system to investigate the semantic properties of compu¬ 
tations with effects in the NXP inference system (which is itself a deductive system 
at a different level of abstraction). Obviously terms such as type, deduction and 
inference have overloaded meanings and we will specify precisely in which context 
or system we use the latter when there is a risk of confusion. 

The rest of this paper is organised in three sections. The first one explores a 
continuation-passing style representation of the NXP computational architecture. 
The second presents generalisation to a monadic style description of various effects 
in the NXP architecture. The last section uses the monadic results of the previous 
exploration to suggest an abstract implementation of the NXP architecture in the 
form of the NXP abstract machine with implications for building theoretically sound 
NXP interpreters or compilers. 

2. Representing inference control with continuations 

2.1. Terminology. In the following we will consider simple languages representing 
various aspects of inference systems, and, more specifically of the NXP architecture. 
Such languages consist of a syntax, defining the set of well-formed types and well- 
typed terms, and a semantics, assigning some notion of meaning to terms. We 
expect a semantics to provide a notion of program evaluation or inference derivation, 
usually represented as a (partial) function from a suitable set of terms to some set 
of observable results, say boolean values. 

In denotational semantics the semantics is expressed as functions mapping syn¬ 
tactic constructs in the program to mathematical objects in a mathematical do¬ 
main. Analyses of programs are actually conducted in the mathematical domain, 
in which properties assessed about denotations of programs translate to properties 
about programs. In contrast, the operational semantics defines an abstract machine 
with a state, possibly several components, and some set of primitive instructions. 
The axiomatic approach associates an “axiom” with each kind of statement in the 
programming language stating what we may assert after execution of that state¬ 
ment in terms of what was true beforehand. There is usually a gap between a 
denotational semantics and an operational semantics for a language and the main 
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formal work in designing interpreters and compilers is to prove their soundness and 
faithfulness by proving equivalence between these semantics. Bridging this gap re¬ 
quires to proceed in several stages: at each stage an alternative semantic definition 
of the language is introduces, embodying successively more and more implementa¬ 
tion details. These intermediate stage semantics are called non-standard semantics 
to reflect their instrumental status. With these sequence of steps, denotational 
techniques often drift into program transformations and non-standard semantics 
have often been used as intermediate languages in compilers. 

2.2. Continuation-passing style transformations. Practically all programming 
languages have some form of control structure or jumping; the more advanced forms 
of control structures tend to resemble function calls, so much so they are rarely de¬ 
scribes as jumps. The library function exit in C, for example, may be called 
with an argument like a function. Its whole purpose, however, is utterly non func¬ 
tional: it jumps out of arbitrarily many surrounding blocks and pending function 
calls. Such a non-returning function or jump with arguments is an example of why 
continuations are needed. 

In continuation-passing style, a function call is transformed into a jump with 
arguments to the callee such that one of these is a continuation that enables the 
callee to jump back to the caller. This idea has been formalised into a standard 
CPS transformation for lambda calculus. 

Definition 2.2.1. The pure untyped lambda calculus A is defined by Q]: A set of 
terms, M, inductively generated over an infinite set of variables Vars, 

• Terms M ::= V\ M M; 

• Values V ::= x\ Xx.M, x in Vars. 

The standards CPS translation for A in denotational semantics is given by the 
map : a ^ a originally described by Fisher: 

Definition 2.2.2. Let k, m, n in Vars be variables that do not occur in the 
argument to 

• [[V]]f = Xk.kij{V) 

• [[MN]]f = Xk.[[M]]F{Xm.[[N]]FXn.(mk)n) 

• '(/’(x) = X 

• iplXx.M) = Xk.Xx.[[M]]Fk 

We will consider a much simpler fragment for the purpose of analysis of effects 
and control in inference systems and, more specifically, in the NXP architecture. 
The syntax is made up of simple expressions of boolean arithmetic: 

E ::= true \false \E or E \E and E 

In this simplihed core model of the inference computation, goals are represented 
by and/or tree expressions, the leaves of which are the working memory elements. 
Keeping with the essentials, these working memory elements are valued in B = 
{0,1} the boolean algebra with boolean operations & (logical and) and | (logical 
or). This will be relaxed later as we take into account other effects in the NXP 
architecture. In this toy model, the pattern-directed modules or production rules 
of inference systems are captured by expressions in the language, and the executive 
system is naturally a boolean arithmetic evaluator. 
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Following the denotational semantics approach, the standard semantics for the 
simple and/or language is defined by: 

Definition 2.2.3. Let B = {true, false} be the set of constants, Exp the set of 
expressions inductively defined as in the previous paragraph, and B the classical 
boolean algebra, we define the semantic function ;B : B ^ B and the evaluation 
function [[_]]o : Exp —> B by: 

. [[B]]o = B{B) 

. [[E, or i?2]]o = [[Ei]]o I [[E2]]o 
• and E 2 ]]o = [[-E’i]]o & [[-£' 2 ]]o 


This definition does not specify a particular order for evaluation of boolean 
expressions, nor does it refer directly to continuations. As such it is really denota¬ 
tional and only calls for several steps of refinement to be turned into an operational 
semantics, ft does, however, reflect the basic principles of inference systems intro¬ 
duced earlier and, properly extended, will be an adequate basis on which to build 
the analysis. The next step towards operational semantics now consists of provid¬ 
ing a non-standard semanti cs for the simple language and proving its denotational 
equivalence with definition 2.2.3. 


2.3. Two non-standard semantics of computations in the NXP architec¬ 
ture. 


2.3.1. Continuations to order goal investigations. The first non-standard semantics 
introduced here makes explicit reference to continuations. In order to better model 
the behaviour of inference systems, we add a new operator to our simple and/or 
tree language to capture sequential investigation of two or more goals: 


E ::= true \ false \E or E \E and E\E ; E 

where E are expressions as in definition 2.2.3| , and Ei ; E 2 describes investigation of 
goal El followed by investigation of goal i? 2 - In imperative programming languages, 
this is simply the succession of computations of expressions Ei and i? 2 - We can 
now define the following non-standard semantics for this new language as follows: 


Definition 2.3.1. Let K be the set of continuations, in our case the set of functions 
B O where O is the type of output obje cts w ith a distinguished element exit : 
B —> O, and B, Exp and B as in definition 2.2.3, we define the evaluation function 
[[.]]i : Exp by: 

• [[B]]i k = k B{B) 

• [[Ai or E 2 ]]i k = [[£;i]]i(Aei.[[£' 2 ]]i(Ae 2 -A:(ei | £ 2 ))) 

• [[El and E 2 ]]i k = [[Ei]]i{Xei.[[E 2 ]]i{\e 2 .k{ei € 2 ))) 

• [[Ei; E2]]ik=[[Ei][i{[[E2[]ik) 


The continuations introduced here follow the convention of mapping results of 
computations, here values of goals inferred by the system, to a specific output type. 
With these conventions in place, the top level read-eval-print loop of traditional 
interpreters is captured by the simple semantics 

[[A]]i exit 

which basically executes the computation of the expression E and pass the result to 
the continuation that yields control back to the user. In addition, definition ^.3.1 
introduces a left to right ordering of goal investigation and a left to right ordering 
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of the data collection process: this appears in the semantics denotation in places 
where the left subexpression of a composed expression is always evaluated first 
with a continuation built from the computation of the right subexpression. This 
of course, is already a form of design choice and alternative semantics are easily 
produced to represent other options. The embedded design choice then goes one 
step further away from the standard denotational semantics down the road of an 
implementation-ready operational semantics. 


2.3.2. Sequence semantics for continuations. With the refined non-standard seman¬ 
tics introduced in this section, we are setting up a framework for representing the 
semantics of control of in the NXP arc hitect ure. The following definitions refine 
the operational semantics introduced in ^.3.1 : 

Definition 2.3.2. We will use the notation s = {Bi, B 2 ...Bn) for finite sequences 
of boolean values, s in B* the set of finite sequences of boolean values; we will also 
use indifferently nil and () to designate the empty sequence. The finite sequence 
abstract data type is characterised by the following operations: 

s J, f = Bi, 0 < i < n {selection) 
s t * = {Bi+i, ...Bn), 0 < i < n; nil, i = n (rest) 
length{s) = n 

s + s’ = {Bi, B 2 ...Bn, B'l, B' 2 ...B'^) {concatenation) 

Or{s) = (sj,l|si2)-|-st2,n>2 
And{s) = (s|l&sj,2)-|-st2,n>2 


The sequence abstract data type is comparable to the stack data type introduced 
by Stoy for operational semantics of programming languages, fn the NXP 
architecture the sequence semantics captures the succession of goals investigated 
and evoked by the systems. Based on definition 2.3.2 we are now able to present 
the (non-standard) sequence semantics for our simple representation of the NXP 
architecture: 


Definition 2.3.3. Let B* be the set of finite boolean values sequences with the 
previ ously defined abstract data type operations, let Exp a nd B be as in definition 
2.3.1 let B be, as before, the semantic function of definition ^.2.3 , we introduce the 
new semantic evaluation function [[_]]2 : Exp —*■ B* —> B*: 

. [[B]]2S = {B{B)) + s 

• [[El or E2][2 s = Or{[[E2]]2{[[Ei]]2 s)) 

• [[Si and E 2]]2 s = And{[[E 2 ]] 2 {[[Ei ]]2 s)) 

• [[El ■ E2]]2 s = [[E2]]2 {[[Ei]] 2 s) 

Remark 2.3.4. Note that, even though the notation is reversed, compared to def¬ 
inition ^.3.1 , the previous evaluation function still enforces a left to right order of 
evaluation on expressions and subexpressions. The left subexpression is always eval¬ 
uated first and pushed on the sequence before evaluation of the right subexpression. 
This is particularly important in the specific case of expressions like Ei ; i? 2 - 


Remark 2.3.5. In the sequence semantics of the simple NXP language, continua¬ 
tions are actually “implemented” as finite sequences, initially with type operations 
similar to stacks (sequence and rest, for instance). In the NXP architecture, the 
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boolean values leaves of and/or trees are determined from examination of the work¬ 
ing memory or from interaction with the user (asking questions). This operation is 
not captured in the simple language we have presented so far but will be discussed 
later. It is important however it somehow constrains when operations are actually 
performed on a finite sequence s of B*. Namely, we consider that boolean values 
in a sequence s are valued just in time when they are passed as arguments to the 
sequence operations And^ Or, and the like. (This can be compared to lazy evalua¬ 
tion in languages like Scheme or Haskell.) Boolean values in sequences of definition 
2.3.3| are then representations of delayed accesses to the working memory. The 
reifications of those delayed executions, usually called thunks, are triggered by the 
goal investigation process as needed. The lazy evaluation convention though does 
not affect the inference computation nor the control of its unfolding. 


We ground the previous definition with the following result: 
Proposition 2.3.6. The semantics 2.2.t\ and 2.3.S are congruent i.e. 

mhs={[[E]]o)+ s 

for all E and for all s. 


Proof. The proof is by induction on expressions. Obviously : 

[[B ]]2 s = {B{B)) + s 

by definition. For the other syntactic forms of expressions : 

[[El or E 2]]2 s = Or{[[E 2 ]] 2 {[[Ei ]]2 s)) 

= Or{[[E 2 M{[[Ei]]ii)+ s)) 

= Or{{[[E 2 ]]o) + (([[T;i]]o) + s)) 

= Ori{[[E 2 ]]o,[[Ei]]o)+ s) 

= {[[E 2 ]]o I [[t;i]]o) + s 
= {[[El or E2 ]]o) + s 

and similarly for the and expression. □ 


2.3.3. Formalisation in a Logical Framework (Twelf). The previous approach lends 
itself to formalisation in a Logical Framework. In this section, we use the codifi¬ 
cation of formalisation techniques into a meta-language offered by Twelf, a logical 
framework developed at Carnegie-Mellon University [^, to specify proofs of in¬ 
ference systems properties. This is done in three stages : The first one is the 
representation of the abstract syntax of the simple language under investigation; 
the second stage is the representation of the language semantics (both notions of 
values and types, and notions of computations, i.e. operational semantics); the last 
stage is the representation of the properties of the language (for instance, congru¬ 
ence of semantics and type preservation). 

We base the representation of the simple language expressions on abstract syntax 
(rather than concrete) in order to expose the essential structure and focus on the 
semantics and its properties rather than on lexical analysis and parsing—although 
the Logical Framework could also help here. The representation technique is called 
higher-order abstract syntax and basically uses types in Twelf to capture all syntax. 
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Definition 2.3.7. Going back to definition 2.2.3 of the simple NXP language, we 
then declare a new Twelf type: 

exp : type. 


to represent expressions of Exp^ intending that every Twelf object M of type 
exp represents a simple language expression and vice-versa. Similarly, we declare 
boolean values as a new Twelf type: 


bool : type. 

and declare two distinguished instances of this newly defined bool type: 

true : bool. 


false : bool. 

With these basic types in place we now turn to boolean values expressions built 
from & and | operators. Twelf captures these operators as expression constructors 
which translate into constant functional types: 

& : bool — > bool — > bool. 

I : bool — > bool — > bool, 
for which we will use infix mode for better readability. 

In a second stage we introduce a representation of deductions following the idea 
of judgements-as-types. In Twelf, deductions are objects and judgements are types, 
so that proofs in the semantics space are in fact type reconstructions in Twelf. In 
order to do so, we introduce a type family evalO indexed by representations of 
expressions (Exp) and boolean values (B): 

evalO : exp — > bool — > type. 

such that we have types such as evalO e b which depend on objects. 

Axioms are simply represented as types such as these, while semantics operations 
can be viewed as constructors which, given deductions of their arguments, yield a 
deduction of their result. 


Definition 2.3.8. For the simple NXP language we introduce: 

constant : bool — > exp. 
and : exp — > exp — > exp. 
or : exp — > exp — > exp. 

and the following representation of their respective evaluations: 

evalOcst : evalO (constantB) B. 

evalOor : evalO (E2 or El) (VI | V2) < - evalO El VI < - evalO E2 V2. 
evalOand : evalO (E2 and El) (Vl & V2) < - evalO El VI < - evalO E2 V2. 
which capture the standard semantics of definition p.2.5 . 

Remark 2.3.9. Using Twelf built-in deductive capabilities we can now explicit de¬ 
ductions such as in the following example: 

evalO (constant true and constant true or constant false) V. 

- Solution 1 - 

V = (false I true) & false. 

A = evalO_and evalO_cst (evalO_or evalO_cst evalO_cst). 
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which simply shows the result of the boolean operation as V and the deduction as 
A. Note that the deduction A may be considered as a logical proof of the value V or 
alternatively as the logical program implementing evalO viewed as a function call. 

The non-standard semantics of the NXP architecture are captured in the same 
way, with the introduction of an additional Twelf type, bool_seq for sequences of 
boolean values. 

Definition 2.3.10. The Twelf representation of the sequence semantics for NXP 
consists firstly of an evaluation function which builds a functional programming 
style representation of expressions of the simple language : 

7o7o7« The sequence abstract data type 

nil : bool_seq. 

atom : bool -> bool_seq. 

select : bool_seq -> int -> bool, 

tail : bool_seq -> int -> bool_seq. 

length : bool_seq -> int. 

+ : bool_seq -> bool_seq -> bool_seq. 7oinfix right 10 +. 

7o7o7« The functional prograunming style representation 
eval2 : exp -> bool_seq -> bool_seq -> type. 

eval2_cst : eval2 (constant B) nil (atom B). 
eval2_cst2: eval2 (constant B) S (atom B + S). 
eval2_or_s : eval2 (El or E2) S (or_s S2) 

<- eval2 El S SI <- eval2 E2 SI S2. 
eval2_and_s : eval2 (El and E2) S (and_s S2) 

<- eval2 El S SI <- eval2 E2 SI S2. 
and secondly of an evaluation function that performs the functionally specified 
operations on the input sequence : 
eval2a : bool_seq -> bool_seq -> type. 

eval2a_atom : eval2a (atom B) (atom B). 
eval2a_atom_2 ; eval2a (atom B + S) (atom B + S’) 

<- eval2a S S’. 

eval2a_or_sl : eval2a (or_s (S’’)) (atom(Bl I B2) + S’) 

<- eval2a S’’ (atom B1 + atom B2 + S) 

<- eval2a S S’. 

eval2a_or_s2 : eval2a (or_s (S’’)) (atom(Bl I B2)) 

<- eval2a S’’ (atom B1 + atom B2). 
eval2a_or_s_nil : eval2a (or_s (A1 + A2 )) (atom(Bl I B2) ) 

<- eval2a A1 (atom Bl) <- eval2a A2 (atom B2). 
eval2a_and_sl ; eval2a (and_s (S’’)) (atom(Bl & B2) + S’) 

<- eval2a S’’ (atom Bl + atom B2 + S) 

<- eval2a S S’. 

eval2a_and_s2 : eval2a (and_s (S’’)) (atom(Bl & B2)) 

<- eval2a S’’ (atom Bl + atom B2). 
eval2a_and_s_nil : eval2a (and_s (A1 + A2 )) (atom(Bl & B2) ) 
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<- eval2a A1 (atom Bl) <- eval2a A2 (atom B2). 

The Twelf representation of the sequence semantics function is simply the compo¬ 
sition of the previously shown functions : 
eval2b : exp -> bool_seq -> bool_seq -> type. 
eval2b_l : eval2b ESS' <- eval2 ESS" <- eval2a S" S'. 


Remark 2.3.11. There are many ways the non-standard semantics of t he NXP ar¬ 
chitecture could have been mapped to Twelf’s metalanguage. Definition 2.3. 10| is in 
fact more “operational” than really needed. It separates a functional programming 
equivalent of the expression parsed from the execution of this representation. The 
previous definition emphasises the distinction between instructions and a machine 
executing instructions. The impact of this formal distinction will be discussed in 
the implementation section of this paper. 


Remark 2.3.12. Theorem-proving capabilities of the Twelf environment are also 
extremely useful in assessing properties of the simple language. For instance, as a 
verification of the congruence of semantics we can query Twelf as follows : 

"/.query 1 1 

eval2b ((constant true and constant false) 
or constant true 
or constant false) nil 

S. 

- Solution 1 - 

S = atom ((false I true) I false & true). 

A = 

eval2b_l 

(eval2a_or_s2 

(eval2a_or_sl eval2a_atom 
(eval2a_atom_2 

(eval2a_atom_2 

(eval2a_and_s2 

(eval2a_atom_2 eval2a_atom)))))) 

(eval2_or_s (eval2_or_s eval2_constant2 eval2_constant2) 
(eval2_and_s eval2_constant2 eval2_constant)). 


"/.query 1 1 

evalO ((constant true and constant false) 
or constant true 
or constant false) V. 

- Solution 1 - 

V = (false I true) I false & true. 

A = eval0_or 

(eval0_and eval0_cst eval0_cst) 

(eval0_or eval0_cst eval0_cst). 


which basically shows deductions of proposition 2.3.6 for a particular expression. 


Within this framework we are now ready to set forth the semantics of some of the 
major inference features of the NXP architecture, and, with the Logical Framework 
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mapping introduced in this section, ground some of its behavioural properties into 
mathematical logic. 

2.3.4. Sequence semantics for goal evocation. The sequence semantics previously 
presented was designed to make it relatively natural and simple to express goal 
evocation in the NXP inference architecture. Informally goal evocation, which is 
triggered by the data collection process, queues a goal for postponed investigation, 
once the current threads of investigation complete. In turn, we will see that this 
sequence semantics is suggestive of an operational semantics closer to implementa¬ 
tion. 


Definition 2.3.13. Let us refine the simple NXP language with the following: 
Exp, expressions: 

E ::= b \E or E\E and E\E ; E\b post E 

with 6 in B and where the new expression b post E collects data value b and evokes 
goal E (which, as an expression, is itself an arbitrarily long sequence of expressions). 


The other expressions are as in definition 2.3.3 


The semantics of goal evocation is captured by extending the previous definition 
2.3.3| of sequence semantics with the additional mapping: 


Definition 2.3.14. Let B* be the set of finite boolean values sequences with the 
previously defin ed se lection, rest and concatenation operations, let Exp and B be 
as in definition 2.3.3 let B be, as before, the semantic function of definition 2.2.3 , 

as follows: 


B* 


B* 


we extend the semantic evaluation function [[_]]2 : Exp 

. m^s = {B{B)) + s 

• [[El or E 2]]2 s = Or{[[E 2 \] 2 {[[Ei ]]2 s)) 

• [[i?i and E2]]2 s = And([[E 2 ]] 2 ([[Ei ]]2 s)) 

• [[^1 ; E2]]2 S = [[if2]]2([[£'l]]2 s) 

• [[B post E ]]2 s = {B{B)) -I- s -I- [[L1]]2() 

Remark 2.3.15. The definition of the post semantic function captures the postponed 
execution of the goal investigation. It effectively replaces the current continuation 
with the same followed by the evaluation of a goal or a sequence of goals. The effect 
is of completing first the current goal evaluation process and then pursue with the 
postponed goals evoked during that initial process. 

Remark 2.3.16. Although it is implicit in the definition of sequences, the previous 
definition relies on a left-to-right ordering of operation on sequences as in remark 
2.3.4. If we required an operational semantics closer to implementation, we would 
enforce this by letting sequences hold unevaluated expressions, or thunks, as well 
as instructions of a virtual machine, transforming the sequence abstract data type 
into a conventional stack abstract data type. 

Remark 2.3.17. In a refined operational semantics, we would need to be a bit more 
specific than the previous definition 2.3.14. More formally, we already mentioned 
that boolean values in goal expressions are actually evaluated by accessing the 
working memory of the inference system (possibly causing further interaction with 
the user). The working memory is represented as an environment p, a map from a 
set of variables Vars to boolean values B. Goal expressions then refer to variables 
and the semantic function is expressed in term of p. The map p is partial in the 
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sense that its value is not necessarily defined on all variables at all times. In the 
occurrence of one of these unvalued variables, the goal evaluation process triggers 
an atomic transaction with the user, requesting the value which is then assigned 
in p. In programming languages this caching effect is also known as memoizing 
and can be captured in different ways in an operational semantics. The postponed 
evaluation of goals then proceeds in the environment as resulting from the preced¬ 
ing evaluation cycle. In this, postponed evaluation differs from re-evaluation that 
would, in contrast, proceed from scratch in a new environment po totally undefined. 

With this semantics we can review some elementary results formalising the in¬ 
tuitions underlying goal evocation in the NXP architecture. 

Proposition 2.3.18. Sequencing and postponing goals are commutative operations 
in the following restricted sense: 

[[Bi post El ; B 2 post E 2 ]]s = [[Bi post {E 2 ; Ei) ; i? 2 ]]s 

and 

[[Bi post El ; B 2 post E 2 ]]s = [[Bi ; B 2 post; {E 2 ; £^i)]]s 
Proof. By simple application of the concatenation operation on sequences. □ 


This simply states that a sequence of goals can be locally evoked either as a 
group or individually without affecting the overall behaviour. In the accompanying 
paper, this result will be set in the context of knowledge acquisition mechanisms 
concurrently running with the evaluation process. More specifically, this restricted 
commutativity will be cast in the context of the chunking processes described by 
Newell in the Soar architecture |^. From an implementation perspective, propo¬ 
sition 2.3.18 may be used for optimisation of the execution by preprocessing goal 


expressions, gathering groups of evoked goals rather than processing them individ¬ 
ually. This would seem particularly useful when building a lazy interpreter for the 
NXP architecture. 


Remark 2.3.19. Goal evocation in the NXP architecture is reminiscent of excep¬ 
tions in functional of imperative programming languages. In the latter the current 
continuation is replaced immediately with another one. The behaviour is then to 
abandon the current process and switch to another one. In the former the continua¬ 
tion is just added after the current one; the resulting behaviour being to successively 
go through the processes to their completion. The analogy will be better illustrated 
in the categorical investigation of the NXP architecture in the next section. 

Goal evocation as exemplified by the NXP architecture is an instance of as¬ 
sociative cognitive mechanisms. Theses associative processes are at work in the 
background of the evaluation process itself interacting with it by driving the focus 
of attention of the inference system. While the backward and forward chaining of 
the goal evaluation process could be described as strong or local focus of atten¬ 
tion, goal evocation represents a form of global, weaker forward chaining. More 
generally if learning processes have traditionally been studied separately from the 
performance component of inference systems, in recent resaerch work emphasis has 
been put on accounting for interactions between performance and learning |^. In 
this perspective understanding and representing of inference control are critical as 
control is the operational juncture between the two subsystems. Furthermore the 
representation semantics is of direct service in specifying the implementation of 
inference systems. 
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3. A CATEGORICAL INVESTIGATION OF INFERENCE CONTROL 

3.1. Motivations. Category theory has in the past few years become a tool of 
choice for to investigate properties of programming languages. Because it focuses on 
very high-level properties abstracted from a number of subdomains of mathematics 
(domain theory, topology, set theory, etc.) its results are characterized by a wide 
range of applicability. 

Composition if of the essence of categories. It is only natural that sequencing 
and its variations, which are the basic building blocks of inference systems control 
constructs—as seen in the previous section—, find a well-fit mathematical expres¬ 
sion in categorical terms. In this section, we suggest such a categorical construction 
for analyses of control in inference systems. Starting from the original insight of 
Moggi, we use triples, a categorical construction with its origins in algebra, to 
define effects and controls in the NXP architecture. Following Wadler’s lines of 
exploration we produce a category to account for goal evaluation and goal evoca¬ 
tion in the NXP architecture. Finally, other results in monadic style representation 
of computations offer interesting analogies for the representation of behaviours of 
inference systems, particularly in layering effects around the core categorical rep¬ 
resentation of the architecture. The categorical study of knowledge acquisition in 
inference systems—in its multi-faceted forms—constitutes the major part of the 
companion paper covering the NXP architecture. 

3.2. Categorical background. This section defines the basic notions from cate¬ 
gory theory that we need in the formalisation of the NXP architecture in monadic 
style. Readers are referred to 0 for a comprehensive presentation of categories 
and triples. Let C be a category, we denote by Obj{C) the objects of C and by 
Hom{A, B) the set of arrows with source object A and target object B. 

Definition 3.2.1. If C and D are categories, a functor F : C ^ D is a map for 
which: 

• If / : A —> 5 is an arrow of C, then Ff : FA FB is an arrow of D; 

• F{idA) = idpA', and 

• li g : A^ B, then F{g o f) = Fgo Ff. 

A functor is a morphism of categories, a map which takes objects to objects, 
arrows to arrows, and preserves source, target, identities and composition. More 
generally F preserves a property P that an arrow / may have if F{f) has property 
P whenever / has. It reflects property P if / has the property whenever F{f) has. 

A natural transformation is defined as a ’’deformation” of one functor to another. 

Definition 3.2.2. If F : C ^ D and G : C ^ D are two functors, X : F G is 
a natural transformation from F to G if A is a collection of arrows AG ^ XD, one 
for each object G of C, such that for each arrow g : G ^ G' of C the following 
diagram commutes: 


FG ► GG 


Fg 


Gg 


FG' 


AG' 


GG' 
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The arrows XC are the components of A. The natural transformation A is a 
natural equivalence if each component of A is an isomorphism in D. 

3.3. Triples, monads and categories for computations. Triple or monads are, 
from one point of view, abstraction of certain properties of algebraic structures, 
namely monoids. They are categorical constructs that originally arose in homotopy 
theory and were used in algebraic theory. Moggi § was the first to discover the 
connection between triples and semantics of effects in programming language design. 
Since then the monadic style has pervaded theoretical research on denotational and 
operational semantics. 

Definition 3.3.1. A triple T = {T,r],fj,) on a category C is an endofunctor T : 
C —> C together with two natural transformations r] : idc TT —» T 

subject to the following commutative diagrams: 


aT 


T^v 


TT 


associativity 


T 


expressing associative identity, and: 



T 



expressing left and right unitary identities. The component of /iT at an object 
X is the component of ^ at TX, while the component of at X is T{fj,X); similar 
descriptions apply to rj. 

Remark 3.3.2. There is an alternate way of defining a triple based on a result due 
to Manes. 

Let C be a category with: 

• A function T : Obj{C) Obj{C)\ 

• for each pair of objects C and D, a function iLoTO(C', TZl) ^ Hom{TC,TD), 
denoted f ^ f*; 

• for each object C of C a morphism rjC : C ^ TC; 
subject to the following conditions: 

. For f :C ^TD, f = r,TD of*; 

• for any object C, (rjC)* = idrc, 

. for / : C ^ TD and 5 : D ^ TA, (g* o f)* = g* o f*; 
is equivalent to a triple on C. 


The equivalence results from constructions of triples from adjoint pairs separately 
discovered by Eilenberg-More and by Kleisli. The function (_)* : Hom{C,TD) —> 
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Hom(TC,TD) is also known as the Kleisli star. This alternate definition empha¬ 
sises the connection between a triple and a monoid, an algebraic structure with an 
associative operation and a unit element. Wadler suggested a straightforward in¬ 
terpretation of the Kleisli star in programming language semantics. In this context, 
the purpose of the star operation is to combine two computations, where the second 
computation may depend on a value yielded by the first 0 - More precisely if m 
is a computation of type Tti and k a function from values to computations (such 
as a continuation) ti —> Tt 2 , then k*(rn), or m * fc, is of type Tt 2 and represents 
the computation that performs computation m, applies k to the value yielded by 
the computation, and then performs the computations that results. It binds the 
result of computation m in computation k. Different definitions for the triple T 
and the star operation then give rise to different monads to represent different con¬ 
trol operators such as escape/exit, call/cc, prompt/control or shift/reset 

10 Hi- 


As noted by Wadler and others, monadic and continuation-passing styles ap¬ 
pear closely related |0| . The actual correspondence, however, is formally quite 
involved. Filinski has shown the remarkable result that any monadic effect whose 
definition is itself expressible in a functional language can be synthetised from just 
two constructs: first-class continuations and a storage cell j|, This has direct 
consequences on the feasibility of various implementations of the NXP architecture 
as investigated in the last section of this paper. 


3.4. Monadic style semantics for capturing side-effects. In most program¬ 
ming languages, evaluation may have implicit side-effects that are not predicted 
by the type of the expression. This is typically the case with goal evocation in 
the NXP architecture where collecting data may trigger goals for further, delayed 
evaluation. From their first introduction in the world of programming languages 
triples, or monads, were precisely used to distinguish between values, and compu¬ 
tations whose evaluation may have side-effects. The semantic separation leads to a 
stratified style where a pure functional language, for instance, is used to to express 
the manipulation of values, and one or several monadic sublanguages are used to 
express manipulation of computations 0- Layering several monadic sublanguages 
is formalised using triple morphisms as in Filinski’s |^. Interactions between the 
core functional language and the monadic extensions are mediated by the type 
system which keeps track of the computational effects and their propagation. 

Each side-effect introduces a new type of computation associated to a particular 
triple T. For instance, triples have been defined for effects such as exceptions, 
state, and input/output. Generally speaking, in monadic style semantics the type 
Ta designates a computation yielding a value of type a with possible side-effects. 
The semantics of these side-effects is captured by proper definition of the natural 
transformations of triple T (its unit and Kleisli star). Formally and following Manes’ 
construction, the unit of the triple turns a value into a computation that returns 
that value without side-effect: 

rj : a ^ Ta. 

The Kleisli star applies a function of type a ^ T6 to a computation of type Ta, 
basically chaining two computations in succession. Following Wadler’s popular 
notation—of using * as an infix operator—the star operation: 
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represents application of a continuation to a computation of the given type. In 
the following paragraphs we will make the analogy even more explicit by using the 
notation: 

m * Xx.k 

where m and k are expressions and x is a variable. The above can be read as 
follows: perform the computation to, bind x to the resulting value and perform 
computation k. In so-called impure languages, the above notation is similar to: 

let X = m in k. 

Note that, however, that the latter does not properly distinguishes pure types (no 
side-effect) from computation types (with possible side-effects). 

We are now ready to present the monadic style definition of the previous standard 
and non-standard evaluators for the NXP architecture. 


3.5. A monadic style presentation of the NXP architecture. 


3.5.1. The standard evaluation triple. The new presentation is simply a rework of 
the semantic evaluation functions of definition 2.2.3 in terms of the appropriate 
triple, unit, and Kleisli star. 


Definition 3.5.1. The standard monadic style semantic of the simple and/or ex¬ 
pression language is captured by the map eval\ 

eval : Exp —> TB 
eval{b) = pb 

eval{Ei or E2) = eval{Ei) * Xx.eval{E2) * Xy.r]{x \ y) 
eval{Ei and E2) = eval{Ei) * Xx.eval{E2) * Xy.r]{x & y) 


Remark 3.5.2. In the definition above lambda abstraction binds less tightly and 
the application star binds more tightly, so that we can get rid of parentheses. 

Remark 3.5.3. The above evaluation is much more flexible in that is separates values 
from computations. Values are evaluated through the unit semantic function y of 
the triple, while the sequencing of computations is specified by the application star. 
The variations in denotational semantics we explored in the successive definitions 
of the previous section are investigated here by simply changing definitions of unit 
and application. 

3.5.2. The non-standard evaluation triple. In the sequence triple, a computation 
accepts an initial sequence and returns a value paired with the final sequence. 


Definition 3.5.4. The sequence triple T : t ^ r x B* with unit rj defined by 

r]{b) = Xx.{b, (b) -j- x) 

where sequence operations are as in definition 2.3.2|; and with application star 

(*) : Tti (ri ^ TT 2 ) Tt2 

such that: 

m * k = Xx.let {a, Si) = m x Inlet {b, S2) = kaxin{b,S2) 


and the evaluator as in definition 3.5.1 captures the non-standard sequence seman¬ 
tics of the NXP architecture. 
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Remark 3.5.5. The sequence triple is similar to the state triple introduced by Moggi 
and by Wadler to represent programming languages with instructions operating on 
a global state. The seemingly awkward definition of the application star simply 
expresses the intermediary sequences and results of first computing m and then 
applying k to the result. 


Remark 3.5.6. For eval uation purposes, the eval semantic function of the generic 
interpreter of definition 3.5.1 has T B as its domain, meaning that computations 


with the sequence triple are of type B x B* as expected. 


In order to introduce goal evocation as a last touch to the sequence triple, we note 
that goal evocation is only a side-effect and does not interfere with values. This 
critical characteristic which was somewhat implicit in the previous continuation 
passing style presentation can now be made explicit in the monadic style. We 
formalise this separation by defining an additional semantic function in the sequence 
triple T: post of type T (), i.e. () ^ () x B*. The () type signals that the post 
function is only concerned with effects on sequences and basically ignores pure 
values. 


Definition 3.5.7. The evocation function for the sequence triple is defined by: 

post : T 0 

and 

post E = As.((), s + inr(i?)) 
where inr is the right injection B x B* —> B*. 

With the evocation function thus defined, we extend the definition of the stan¬ 
dard interpreter to accommodate the goal evocation expression in the following 
final definition of the sequence triple. 

Definition 3.5.8. The monadic style sequence semantic of the simple and/or ex¬ 
pression language is captured by the map eval in the sequence triple T: 

eval : Exp TB 
eval{b) = rjb 

eval{Ei or E 2 ) = eval{Ei) * Xx.eval{E 2 ) * Xy.r](x | y) 
eval{Ei and E 2 ) = eval{Ei) * Xx.eval{E 2 ) * Xy.r]{x & y) 
eval(b post E) = postE * rjb 


In that definition we simply replaced rjb with post E * tjb in the computation. 
Properties of natural transformations assure that the call to post indeed percolates 
through higher-level goal evaluations. In the definition 3.5.8, as in the previous 
section definitions we insist on a left-to-right evaluation ordering of sequences. 


Remark 3.5.9. Note that the definition oipost could be viewed as a family of seman¬ 
tic functions indexed by goals, E in the representation. A better notation in this 
case would be postE to capture goal indices. Although equivalent in the monadic 
style presentation suggested above for the NXP architecture, this alternative no¬ 
tation will help formalise the knowledge acquisition part of the NXP inference 
architecture. 
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4. Operational semantics and implementation issues 

4.1. Layering effects in the NXP architecture. Filinski’s and Wadler’s work 
1^ have emphasised the compositional nature of triples in representing compu¬ 
tations. Filinski’s results in particular are geared towards presenting a framework 
for computational effects which makes it possible to describe effects in a modular 
way—an idea which permeates the design of the Haskell functional programming 
language, to mention only one. Drawing on the latter framework, we are able to 
add inference effects, so critical to the NXP architecture and to inference systems 
at large, incrementally. Following this approach, the NXP architecture is actually 
specified by a sequence of definitional translations, each one of which “translates 
away” one level of inference effects. For example, we can refine the description of 
the NXP architecture with goal evocation and dynamic working memory by spec¬ 
ifying it as a composition of a goal evocation and a working memory translation. 
Informally we will also talk of composing a goal evocation and a working memory 
triple. 

The monadic composition relies on the following general idea: assume we have 
two triples T and U over a base language L, where C/ is in a certain sense “more 
general” than T. There is a standard translation of effects, into the base 
language given their monadic representation. Using this monadic translation we 
can give two different translations from to L: the original monadic translation 
for T and a variant translation using [/-representations of T-effects, inducing the 
same evaluation semantics. The reader is referred to for a formal proof of these 
results—interestingly enough the crux of the demonstration relies on the result that 
continuations are in a precise sense a universal effect: any definable triple can be 
simulated by a continuation triple on a language with only first-class continuations 
(a la Scheme) and typed states. 

We present here other control constructs of the NXP architecture and propose 
candidates for their formal monadic representation. The working memory, a major 
element of the NXP architecture, is detailed by itself in the next section. 


4.1.1. Associative links, context. In the NXP architecture, the data-triggered goal 
evocation mechanism is complemented by second goal-triggered goal evocation pro¬ 
cess based on associative links between goals and goals or subgoals. Associative 
links are defined by a binary relation: the contextual relation. 


Definition 4.1.1. The simple base language for inference systems expression is 
extended with the context expression. Let us define Exp, the set of expressions: 

E ::= b \E or E\E and E\E ; E\b post E\E context E 


with 6 in B and where the new expression E context E evaluates the first expression 
and evokes the second (which, as an expression, is itself an arbitrarily long sequence 


of expressions). The other expressions are as in definition 2.3.13 


Remark 4.1.2. The goal-triggered goal evocation has lower priority than the data- 
triggered one. In the concrete expression Ei context E 2 , any goal evoked by 
the evaluation of Ei through post subexpressions will be evaluated before actual 
evaluation of E 2 . Priorities aside context and post have the same semantics. 


We reuse the sequence triple to capture the semantics of the context links in the 
NXP architecture. 
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Definition 4.1.3. Associative links semantics in the NXP architecture extend the 
aval semantic map in the sequence triple as follows: 

aval {El aontaxt E 2 ) = postE 2 * aval{Ei) 

Remark 4.1.4. Note that the post primitive is now used twice: in the triple sequence 
used to capture goal evocation, and in the second triple sequence used to capture 
context links. 

In some respect, associative links are higher level control constructs in inference 
systems. Compared to pattern-directed modules of the canonical architecture, they 
do not rely on actual patterns in the working memory elements but rather on the 
behaviour of the inference process itself, posting goals for later evaluation when 
the inference, seen as computation, reaches some particular goal or subgoal. Alter¬ 
natively the composition of identical sequence triples could also be viewed as the 
more general triple defined by T : r —> r x B* x B* where the second sequence is 
in fact used for contextually linked goals. 

4.1.2. The reset action. Independently of the various actions operating on the 
working memory, calling for a special treatment as explained in the next section, 
the NXP production rules support a reset action on a variable with the immediate 
effect of setting its value to “unknown” regardless of its previous assignment. 

From the behavioural standpoint, the representation of the computation of such 
an expression is simply to unevaluate it. When reset operates on a data, the 
semantics is simply to reevaluate it should the computation need it at some later 
time. When reset operates on a goal (an expression in the simple NXP language) 
however, the situation is quite different: indeed the reset goal, considered as data 
in a later computation, should be reevaluated but what of its antecedents? And 
what if further computations do not explicitly need the reset goal? 

In the NXP architecture the effect of the reset action propagates back from the 
goal to its antecedents but does not affect posted goals from evocation or contextual 
links. This propagation only interferes with the computation process by forcing a 
reevaluation, i.e. a new expansion of the reset expression. Its semantics is handled 
by the working memory executive which mediates all accesses to values. 

4.2. Working memory and user interaction. In the semantics definition of 
the previous sections we oversimplified an essential element of an inference system, 
namely the working memory. The working memory is holding the data structures 
on which the pattern-directed modules operate. In the traditional view of inference 
systems, data is often said to enter or leave working memory as it is added or 
deleted by the action part of those modules. In the cognitive sciences framework, 
the working memory is the representation in inference systems of the short-term 
memory. Inflow and outflow of data in working memory capture the essentially 
focal characteristic of short term memory which can only hold a limited number of 
items (“the magic number seven”) and only for a short period of time. 

In most inference systems, and particularly in traditional production systems 
where pattern-directed modules are production rules, the working memory is usu¬ 
ally structured as a database of records. Working memory elements are instances 
of pre-defined or user-declared data structures with typed attributes. The pat¬ 
tern parts of the pattern-directed modules simply express boolean conditions over 
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these attributes or, in some cases such as in the OPS series of production system 
languages 0, the presence or absence of particular records. 

As such the basic structure is similar to the concept of an environment in denota- 
tional semantics. An environment tells what the identifiers mean in an expression: 
it says what values the identifiers denote. In order to capture the level of indi¬ 
rections, it it usual to introduce Ide a set of identifiers (variable names) and the 
domain U of environments as C/ : Ide ^ 'R. With this the simple NXP language 
complies with the following definition. 

Definition 4.2.1. Exp is now the set of expressions : 

E ::= X \E or E\E and E\E ; E\ x post E\ E context E 
with X in Ide. 

In the NXP architecture, the working memory additionally plays a much more 
dynamic role. In a major departure from the closed world assumption of former 
inference systems, the working memory of the NXP architecture is also the locus 
of interaction with the external environment, whether data is captured through in¬ 
teractions with users or from other applications and systems. Indeed the historical 
implementation, Nexpert Object, is famous for its pioneering use of API (Applica¬ 
tion Programming Interface) and middleware to integrate inference capabilities to 
entreprise applications and information systems in heterogeneous environments. In 
order to fulfil this role, the NXP working memory has its own low-level simplified 
executive module whose responsibility is to plan for the acquisition of the value of 
a particular data required by the inference process. In most cases, the plan is a 
simple look-up of the value for the requested data in memory. If this fails, either 
because the value is unknown yet or because a previous inference operation has 
reset that particular data item, the value is sought outside the NXP system either 
by asking the user (this in the form of a popup question window) or by sending 
the request to the middleware layer to distant databases and applications {Nexpert 
Object has a wide variety of foreign request mechanisms ranging from file load¬ 
ing and SQL queries up to COM or Corba-based dynamic queries to application 
servers). Beyond the marshalling of the returned value, its type conversion, the 
working memory executive is also able to synchronise the request for value with 
the higher-level chaining and goal-driven processes. It may pre-process group of 
requests and use caching in order to optimise usage of costly data access channels, 
for instance. 

A second dimension of dynamic behaviour that sets the NXP working memory 
apart from former production systems architecture is the evolutive nature of the 
working memory structure. This aspect is fully developed in the companion paper, 
but let us simply state here that the NXP architecture allows for pre-processing of 
the working memory elements based on previous runs of the inference systems. This 
pre-processing helps determine the initial focus of attention of the system which, 
in turn, assigns priorities in the goal-driven process. This experience-based skill 
acquisition process differs from historically studied machine learning processes con¬ 
cerned with alteration of the collection of pattern-directed modules, or production 
memory, e.g. chunking 

Operations of the working memory mini-executive are transparent to the seman¬ 
tic definitions of previous sections. An operational semantics that would be closer to 
actual implementation would replace the simple set of boolean constants, B, with 
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a family of semantic functions gets, indexed on a set of variables, representing 
working memory elements and capturing the simple semantics of request-response 
interactions with the external environment. Those functions could be further refined 
either in an asynchronous framework, accounting for message-based communication 
channels for instance, or in a lazy evaluation framework in which the mini-executive 
is implemented as a lazy interpreter. 

The monadic style representation of the semantics of NXP architecture’s working 
memory follows the layered approach discussed in the previous subsection. By 
analogy with Haskell’s I/O monads [||, we introduce the following definition. 

Definition 4.2.2. The working memory monad W describes a computation as a 
series of channels paired with the value returned. 

type kb b={Ci,--- ,Cn,b) 
r] :b ^ Wb 
77a; =(*!,• •• ,*n,x) 

{*) :Wbi (&i ^ WM 62 ) -^Wb2 
m* k =let (csa;i, • ■ • , csXn, bx) = m In 
let {csyi, • • • , csyn, by) = k bx In 
{csxi;csyi, • ■ • , csXn] csyn, by) 


where channels, Ci, represent distinct request-response communication channels; 
csXi denotes state x of channel Ci] denotes the undefined (in the strict sense) 
state of channel Ci ; bx and by denote boolean values from B, and csXi] csyi denotes 
the state of channel Ci after stepping through state csXi then csyi. 

Remark 4.2.3. The previous definition does not specify the operational semantics 
of communication channels. In an operational semantics, channels would use the 
state monad which simply captures that requests and responses flowing through 
the channel change its state. The definition also leaves the number of channels 
unspecified. In the NXP architecture, at least one of these channels is identified 
as the user interaction channel through which question-answer based interactive 
transactions can be set up. 


Remark 4.2.4. This definition also leaves the choice of channel state semantics open. 
In particular, different semantics are called for synchronous and asynchronous com¬ 


munication patterns. Similarly, definition 4.2.2 excludes interaction between com¬ 


munication channels oversimplifying some of the capabilities of the mini-executive 
in the Nexpert Object reference implementation of the NXP architecture. 

The advantage of the monadic style is in this instance twofold. Firstly, in the lay¬ 
ered approach outlined in the previous paragraphs, the composition of monads ad¬ 
equately reflects the juncture of the inference processes, chainings and goal-driven, 
with interactive processes. Here this articulation is naturally represented by the 
composition of the NXP monad from definition 3.5.8 with the working memory 
monad from definition 4.2.2. This architectural pattern will be reused in the com¬ 


panion paper to present the composition of inference with associative and dynamic 
memory processes. 
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Secondly, it brings forward the nature of the working memory mini-executive 
itself and suggests various operational implementations. In particular, lazy inter¬ 
pretation could be useful in the case of continuous data streams channels, for in¬ 
stance, or for combined management of interacting communication channels—both 
situations quite frequent in real-time enterprise application integration. 

4.3. Operational semantics: an NXP machine. As a last step towards an 
operational semantic for the NXP architecture, we will think of the computation 
as described by the operation of a state-based machine: 

until term{a) do ct = step{a) 

At each stage of the machine’s operation the state, a, is modified to a new state 
as specified by the single step state transformation function step; this is repeated 
until a terminal state, recognised by the predicate term, is reached. The operation 
is captured by a formal definition. 

Definition 4.3.1. With S a set of states, step : S ^ S a function from states to 
states, and term : S' —> B a function from states to truth values, we define the 
general machine function : 

machine(step, term) = fix{XfXa.±f term{a) then cr else / o step{a)) 

where the expression if ... then . . . else has the usual meaning and where 
fix is the fixed point operator (here acting on /). 

Remark 4.3.2. With this very general definition a machine is simply identified by 
the couple of functions step and term. 

In order to exhibit an example of an NXP machine, we will transform the se¬ 
quences of the previously described non standard semantics into operational se¬ 
quences. Here the denotational semantics naturally suggests an operational seman¬ 
tics: instead of queuing up denoted values in sequences, we now queue instructions 
for the NXP machine sequences. Each expression of the simple language is compiled 
into a sequence of mixed instructions and arguments, constituting a program then 
passed to an abstract machine (with proper term and step definitions). 

Definition 4.3.3. We introduce the syntactic domains: B of boolean values. Ins 
of instructions, Prg = Ins* of finite sequences of instructions, or programs. 

The syntax for instructions is: 

/ ::= get x |and |or [reset x 

The semantics of this machine code will basically arrange that, as might be ex¬ 
pected, get accesses the working memory to retrieve the value of a particular 
identifier—possibly triggering side-effects in the working memory executive—and 
place it on top of the sequence; or will form the logical or of the top two elements 
on the sequence; similarly for and; and reset which causes the working memory 
executive to reset values used in the evaluation of a variable-possibly triggering 
side-effects. 

Remark 4.3.4. With this definition in place we have shifted emphasis from a seman¬ 
tic function mapping expressions to denotations to a compiling function mapping 
expressions to syntactic values, namely sequences of instructions. 
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The compiling function transforms expression into programs fit for the NXP 
machine. 

Definition 4.3.5. Following the lines of the non standard semantics, we introduce 
the compiling function C : Exp x Prg x Prg —> Prg x Prg. 

C{x,s,p) = s + (get x),p 

C{Ei or E2,s,p) = let s',p' = C{E 2 ,C{Ei, s,p)) in s' + (or),p' 

C{Ei and E 2 , s,p) = let s',p' = C'(i? 2 , C{Ei, s,p)) in s' + (and),p' 

CiEi ; E2,s,p)=C{E2,C{Eus,p)) 

C{x post E, s,p) = let s',p' = C{E, (), ()) in s' + (get x),p' -\- p 
C{Ei context E 2 , s,p) = let s',p' = C'(i? 2 , (), ()) in C{Ei, s,p),p' + s' + p 


Remark 4.3.6. In this definition we need two operational sequences s and p. The 
first one represents direct continuations as processed by evaluation and evocation 
of goals. The second one is used to process contextual links and goal associations. 

Remark 4.3.7. As remarked in the previous section, the compilation process could 
be captured by a specihc triple then blurring the formal distinction between com¬ 
pilation and semantic evaluatiation of NXP simple language expressions. 


We now complete the definition of an operational semantics for the NXP archi- 
tectu re b y disp laying a term and a step function for the compiled code definitions 
01 and ^31. 


Definition 4.3.8. Let S = Prg x N x B* be a set of states, and a = (If, n, s) be a 
typical member of S. Simply enough, we specify the effect of any single instruction 
on the stack by dehning a function I: Ins ^ B* ^ B* as follows: 


/(get X, s) = {get{x)) + s 
/(reset x, s) = s 

/(or , s) = Or(s) 

/(and , s) = And(s) 


Remark 4.3.9. In this definition get and reset are invocations of the working mem¬ 
ory executive. In fact reset : Ide ^ {) always returns the empty stack while 
get ■. Ide ^ ^ returns the boolean value denoted by identiher x —both calls having 
possible side-effects. The semantics of these calls is represented by the working 
memory triple. 


Finally we dehne an instance of the abstract machine. 


Definition 4.3.10. The NXP virtual machine is defined by the set S of states, 
and the term and step functions: 

step(n, n, s) = (If, n -I- 1, /(n J, z, s)) 


and 


term{Il, n, s) = n > length{lV) 
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Remark 4.3.11. Thus when the machine executes a program 11 with the starting 
stack s-usually the empty stack ()-the final stack is obtained as specified by the 
semantic function M, defined by: 

M ■. Prg ^ B* 

M(n, s) = m 3 (machine(step, 1, s)) 


where m 3 is the canonical projection of the third element of the triplet. 

Remark 4.3.12. Note that the final program passed to the NXP machine is the 
concatenation of the two compiled operational sequences, accounting for the lower 
priority of the associative links. This is captured in the following congruence propo¬ 
sition. 

Proposition 4.3.13. The effect of running a compiled expression is the one given 
by the sequence semantics, more specifically: 

M{U,s) = [[E]] 2 S 

where 

n= let s',p' = C{E,s,(}) Inp' + s' 

for all E, s. 

Interestingly enough the compiler is not the only operational semantics suggested 
by the non standard semantics studied above. Building an interpreter for the NXP 
architecture is also possible along the same lines as the compiler, but instructions 
are then executed on the fly. More generally several implementations can still be 
chosen at this stage, somehow independently of the operational semantics: eager 
or lazy evaluation, for instance, is applicable to both operational semantics. 

5. Conclusions and further research 

Inference may be considered as a special form of computing. This basic tenet of 
the whole Artificial Intelligence theoretical field has been comprehensively captured 
by Newell’s knowledge level hypothesis , and if the distinction between behaviour 
and beliefs is well established, the nature of behaviour as computation is still much 
debated. 

Inspired by the analogy between the latter distinction and the one usually drawn 
between computations and values in the study and design of programming lan¬ 
guages, we have presented an architectural view of control constructs in inference 
systems and, more specifically, of Nexpert Object as a canonical inference system. 
The resulting NXP architecture has grounded semantics expressed in categorical 
terms using the monadic style of presentation. 

The benefits of this formal representation is twofold. On the one hand, the 
categorical foundation of this representation helps study of the NXP architecture in 
a logical framework, such as Twelf, and formally assess its architectural properties. 
On the other hand, the denotational (and derived non standard) semantics strongly 
suggest operational semantics for the implementation of the NXP architecture. 
Formally provable congruence relation henceforth ascertain the soundness of the 
resulting implementation. 

Finally the categorical foundation of the NXP architecture extends to the for¬ 
mal representation of other cognitive processes beyond inference. In particular the 
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monadic style can be used to articulate the working memory process to inference 
in a modular way. It can also be used to express relationship between inference 
and learning or adaptative processes reflecting the long term effect of experience 
on inference. 
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